Evaluating the potential of programmable multiprocessor cache controllers

technical reportThe next generation of scalable parallel systems (e.g., machines by KSR, Convex, and others) will have shared memory supported in hardware, unlike most current generation machines (e.g., offerings by Intel, nCube, and Thinking Machines). However, current shared memory architectures are constrained by the fact that their cache controllers are hardwired and inflexible, which limits the range of programs that can achieve scalable performance. This observation has led a number of researchers to propose building programmable multiprocessor cache controllers that can implement a variety of caching protocols, support multiple communication paradigms, or accept guidance from software. To evaluate the potential performance benefits of these designs, we have simulated five SPLASH benchmark programs on a virtual multiprocessor that supports five directory-based caching protocols. When we compared the off-line optimal performance of this design, wherein each cache line was maintained using the protocol that required the least communication, with the performance achieved when using a single protocol for all lines, we found that use of the "optimal" protocol reduced consistency traffic by 10-80%, with a mean improvement of 25-35%. Cache miss rates also dropped by up to 25%. Thus, the combination of programmable (or tunable) hardware and software able to exploit this added flexibility, e.g., via user pragmas or compiler analysis, could dramatically improve the performance of future shared memory multiprocessors

General Terms

In this paper, we describe the prevention-focused and adaptive middleware mechanisms implemented as part of the Advanced Adaptive Applications (A3) Environment that we are developing as a near-application and application-focused cyber-defense technology under the DARPA Clean-slate design of Resilient, Adaptive, Secure Hosts (CRASH) program

Notes on Thread Models in Mach 3.0

During the Mach In-Kernel Servers work, we explored two alternate thread models that could be used to support traps to in-kernel servers. In the "migrating threads" model we used, the client's thread temporarily moves into the server's task for the duration of the call. In the "thread switching" model, an actual server thread is dispatched to handle client traps. Based on our experience, we find that the migrating threads model is quite complex and difficult to implement in the context of the current design of Mach and the Unix single server. The thread switching model would fit more naturally and would probably be much simpler and more robust than migrating threads, making it a valuable approach to explore in the near future. However, we believe migrating threads inherently to be faster than thread switching, and ultimately to be the best long term direction. 1 1 This research was sponsored by the Hewlett-Packard Research Grants Program. Introduction In our Mach In-Kernel Servers..

The Persistent Relevance of the Local Operating System to Global Applications

The growth and popularity of loosely-coupled distributed systems such as the World Wide Web and the touting of Java-based systems as the solution to the issues of software maintenance, flexibility, and security are changing the research emphasis away from traditional single node operating system issues. Apparently, the view is that traditional OS issues are either solved problems or minor problems. By contrast, we believe that building such vast distributed systems upon the fragile infrastructure provided by today's operating systems is analogous to building castles on sand. In this paper we outline the supporting arguments for these views and describe an OS design that supports secure encapsulation of the foreign processes that will be increasingly prevalent in tomorrow's distributed systems. 1 1 Why Global Applications Require More from Local Systems 1.1 The Global Vision The Call for Papers for this conference envisions that an "as-yet-unbuilt system will allow hundreds of millio..

Using Annotated Interface Definitions to Optimize RPC

In RPC-based communication, it is useful to distinguish the RPC interface, which is the "network contract" between the client and the server, from the presentation, which is the "programmer's contract" between the RPC stubs and the code that calls or is called by them. Presentation is usually a fixed function of the RPC interface, but some RPC systems, such as DCE and Concert, support the notion of a flexible presentation or endpoint modifier, allowing controlled modification of the behavior of the stubs on each side without affecting the contract between the client and the server. Up until now, the primary motivation for flexible presentation has been for programmer convenience and improved interoperability. However, we have found flexible presentation also to be useful for optimization of RPC, and in many cases necessary to achieving maximal performance without throwing out the RPC system and resorting to hand-coded stubs. In this paper we provide examples demonstrating this point fo..